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this  sort  of  system  would  facilitate  interfaces  among  commands 
while  not  limiting  participating  commands  to  specific  hardware, 
software,  or  data  base  management  systems.  The  thesis  proposes 
the  EDI  concept  as  a  step  toward  realization  of  better  data 


distribution  and  management  in  WWMCCS  ADP. 


4 


TABLE  CF  COHTEHTS 


I.  INTBCDUCT IOH  .  7 

II.  BACKGROUND . 9 

A.  WWHCCS  ADP  OBJECTIVES  .  9 

B.  WWHCCS  ADI  HANAG SHEET . 11 

C.  BWHCCS  ADP  STANDARD  APPLICATIONS  SOFTWABE  .  .  12 

III.  PBOBLEHS . 14 

A.  THE  CPE  EIVIBONHENT . 14 

1.  Planning . 14 

2.  Execution . 19 

E.  SPECIFIC  PBOBLEHS . 21 

C.  BEQOIBEHENTS . 25 

IV.  B1CCEHENDATIOSS . 27 

A.  CHANGING  EBVIBONHENT  .  27 

1.  Open  System  Interface  Reference 

Standard . 27 

2.  Local  Area  Networks  (LAN)  . 30 

3.  WWHCCS  Information  System  (BIS) . 30 

4.  Summary . 31 

B.  STANDARDIZATION  -  A  NEW  APPROACH . 33 

1.  Electronic  Data  Interchange  (EDI)  ....  35 

2.  Application  to  Specific  Problems . 42 

C.  IHPLEHENT ITION . 46 

1.  Logical  Data  Base  Design . 48 

2.  Physical  Data  Base  Design . 51 

3.  Summary  . . 56 

V.  SUHHART . 57 

LIST  OF  BEFEBENCES . 63 

INITIAL  DISTRIBUTION  LIST  .  65 


5 


LIST  OF  FIGOBES 


3.1  Deliberate  Planning . 15 

3.2  Crisis  Action  System  .  18 

4.1  Network  Based  on  ISO  CSI  Reference  model  ....  29 

4.2  Oser  Capabilities  Supported  by  NIS  ...  ....  32 

4.3  Interfacing  under  RRMCCS  Today . .  .  33 

4.4  Interfacing  through  a  Standard  Data  Set  ....  34 

4.5  The  Structure  of  a  Transaction  Set . 37 

4.6  A  Communications  Session  .  39 

4.7  Use  of  Tables  in  BDI . 40 

4.8  EDI  Tables  -  Sample  Entries . 41 

4.9  Design  Considerations  for  Databases  as 

Models . 47 

4.10  Data  Dictionary . .  .50 

4.11  List  of  Data  Segments . 52 

4.12  Data  Elements  in  Each  Data  Segment . 53 

4.13  List  of  Transaction  Sets . 54 

4.14  Data  Segments  in  Each  Transaction  Set . 55 

5.1  HNRCCS  Interfaces  Today  .  58 

5.2  Data  Exchange  Using  EDI . 58 

5.3  Transmission  as  Submitted . 61 

5.4  Transmission  in  EDI  Format . 62 


6 


I.  IH IBOOOCTIOH 


la  the  Worldwide  Hilitary  Coaaand  aad  Control  Systea 
(WWHCCS)  current  ADP  capabilities  do  not  provide  sufficient 
support  for  the  exchange  of  data  aaong  coaaands  in  a  tiaely 
and  effective  Banner.  In  order  to  exchange  data  today, 
generally,  coaaands  aust  have  the  saae  hardware  and  soft¬ 
ware.  In  soae  other  cases  specific  software  must  also  be 
developed  to  exchange  and  translate  data  between  applica¬ 
tions  which  are  interfaced.  These  conditions  cause 
inefficient  use  of  resources  and  severely  Unit  capabilities 
to  respond  to  coaaand  and  control  reguireaents. 

Evolving  reguireaents  including  the  developaent  of  the 
Joint  Operation  Planning  and  Execution  Systea  ( J0PE5)  are 
forcing  the  WW9CCS  ADP  coaaunity  toward  the  developaent  of  a 
distributed  data  base  approach  to  inforaation  aanageaent. 
In  this  thesis  the  Electronic  Data  Interchange  (EDI)  concept 
is  exaained  as  a  proposed  systea  for  realizing  a  distributed 
data  approach. 

"The  0.  S.  Electzcnic  Data  Interchange  (EDI)  Standards 
are  designed  to  facilitate  the  electronic  interchange  of 
data  in  a  standard  Banner  between  independently  organ¬ 
ized,  cwned,  and/or  operated  coaputer  and  comaunication 
systems.  .  .  The  EDI  standards  grew  from  needs  in 
transportation  andpayaent  applications  and  have  been 
extended  for  use  in  other  business  and  technical  appli¬ 
cations."  [Bef.  1 :  p.  6  ] 

Implementation  of  this  sort  of  systea  would  facilitate 
interfaces  aaong  coaaands  while  not  liaiting  participating 
coaaands  to  specific  hardware,  software,  or  data  base 
aanageaent  systeas. 


Chapter  II  of  the  thesis  provides  background  by  defining 
VHHCCS,  and  9VMCCS  ADF,  and  explains  the  current  approach  to 
iwaccs  ADP  management.  Chapter  III  discusses  the  problems 
of  data  management  in  conventional  planning  and  execution. 
In  this  chapter  specific  problems  are  identified  along  vith 
documented  requieaents  which  cannot  be  satisfied  using  the 
current  procedures.  Chapter  IV,  Recommendations,  includes 
soae  background  on  current  capabilities  in  ADP.  which  could 
be  exploited  for  better  coamand  and  control.  In  addition 
the  Electronic  Data  Interchange  (EDI)  concept  is  examined  as 
a  proposed  system  for  aeeting  evolving  HWMCCS  ADP  data 
aanageaent  reguireaents.  EDI  is  evaluated  in  its  potential 
to  alleviate  the  specific  problems  which  are  identified  in 
Chapter  III.  Chapter  V  provides  a  summary  of  how  the  EDI 
concept  could  help  improve  data  interchange  among  commands 
and  includes  an  illustration  of  an  EDI  application. 

The  thesis  proposes  the  EDI  concept  as  a  step  toward 
realization  of  better  data  distribution  and  aanageaent  in 
swaccs  AEP. 


II.  BACKGBOOHD 


A.  HiflCCS  ADP  OBJECTIVES 

"The  H8MCCS  is  the  Worldwide  Military  Command  and 
Control  System  that  provides  the  means  for  operational 
direction  and  technical  administrative  support  involved  in 
the  function  of  command  and  control  of  United  States  mili¬ 
tary  forces,"  [Ref.  2].  The  elements  of  HWMCCS  are; 

-  warning  systems 

-  communications 

-  ccmaand  facilities 

-  executive  aids 

-  data  collection  and  processing 

The  fiWHCCS  AOP  System  includes  the  ADP  hardware,  system 
software,  application  software,  data  bases,  files,  proce¬ 
dures,  data  management  system  (s) ,  related  personnel,  data 
communications  equipment,  and  circuits.  The  ADP  support  at 
the  Service  headguarters  and  Service  component  levels  may  be 
a  mix  cf  both  WWMCCS  and  unigue  systems. 


"The  RVMCCS  ADP  system (s)  must  support  both  the  primary 
and  secondary  missions  of  the  R8HCC5  as  stated  in  eod 
Directive  5100.30  and  JCS  PUB  19.  In  doing  so,  the  ADP 
system  will  support  the  command  and  control  requirements 
of  the  Rational  Military  Command  System  (NMCS) ,  unified 
and  specified  comiands,  component  commands,  service 
headquarters,  subordinate  unified  commands,  JTFs,  TO As, 
the  Joint  Deployment  Agency  (JDA),  and  the  Joint 
Strategic  Target  Planning  Staff  (JSTPS) ,  and  related 
functions  of  othe?  defense  agencies.  The  system  must 
support  the  decisionmakers  and  their  staffs  by 
providing ; 


timely  and:  accurate  information  on  the  status  and 
location  of  forces  and  major  resources 


the  capability  to  develop  and  implement  both  conven¬ 
tional  and  nuclear  operations  plans  and  options 


the  capability  tc  formulate  and  transmit  direction 
to  and  receive  and  assess  reports  from  the  appro¬ 
priate  commands  and  organizations 


the  capability  to  rapidly  and  securely  exchange 
information.  Both  laterally  and  vertically,  across 
service  and  command  boundaries... 


In  general,  meeting  these  objectives  vill  result  in  a 
capability  to  capture,  transmit,  and  process  information 
in  a  timely  and  accurate  fashion  and  to  display  useful 
and  easily  understood  formats."  [Ref.  3:  p.  a-2j 

The  WHBCCS  A££  Concent  of  Operations  and  General 
Bequiyem^qts  for  £fl§&il£85  was  approved  by  the  JCS  and  the 
Services  in  1981.  The  documentation  identified  £our  func¬ 
tional  families  of  processing  requirements  within  hhbccs 
AOP •  Host  WHBCCS  applications  software  and  data  bases  can 
be  grouped  into  one  cf  these  functional  families: 

-  Resource  and  Unit  Bonitoring  (BOB) 

-  Conventional  Planning  and  Execution  (CPE) 

-  Nuclear  Planning  and  Execution  (NPE) 

-  Tactical  Warning/ At  tack  Assessment  and  Space  Defense 
(TW/AA  and  SD) 

Conventional  Planning  and  Execution  will  be  used  to 
illustrate  some  of  tte  problems  which  can  result  when  there 
is  insufficient  provision  for  interfaces  among  data  bases. 
Conventional  PI  Awning  and  Execution  (CPE)  generally  includes 
the  development,  maintenance,  and  execution  of  operation 
plans  for  the  deployment  and  employment  of  United  States 
military  forces.  CPE  includes: 

-  Generating  and  refining  operatonal  requirements 

-  flerging  requirements  from  different  plans 

-  Determining  oplan  feasibility 

-  Batching  requirements  with  actual  resources 

-  Developing  and  disseminating  schedules  and  orders 

-  Identifying  shortfalls  and  limitations 

-  Bapidly  reflowing  movement  requirements 


-  Coordination  and  aonitoring  mobilization  and  deploy¬ 
ments 

-  Aggregating  and  summarizing  requirements 

The  CPE  function  relies  heavily  on  ADP  support  espe¬ 
cially  since  the  JCS  has  directed  that  the  Joint  Operational 
Planning  System  (JOPS)  be  used  in  planning  for  operations, 
force  deployaent,  and  support  of  U.S.  Joint  military 
Operations.  "The  JCPS  consolidates  policies  and  procedures 
for  the  development,  coordination,  dissemination,  review  and 
approval  of  joint  plans  for  the  conduct  of  military  opera¬ 
tions,"  [Ref.  4:  p.  3].  In  addition,  the  members  of  the 
Joint  Deployment  Coaaunity  (JDC) ,  which  includes  the  unified 
and  specified  comaands,  component  commands.  Services,  TCAs 
and  JEA,  use  the  Joint  Deployment  System  in  support  of  oper¬ 
ation  plan  execution  and  aonitoring.  To  communicate  and 
coordinate  among  command s  in  support  of  CPE  the  WffflCCS 
Intercomputer  Network  (BIN)  is  used.  Nany  command  and 
service  unigue  software  applications  are  used  to  prepare 
data  for  input  to  JOES  and  JDS,  but  interfaces  among  these 
unique  applications  and  JOPS  and  JDS  are  for  the  most  part 
manual  as  is  the  interface  between  JOPS  and  JDS. 

B.  NRHCCS  ADP  HAHA6EBENT 

The  management  approach  which  has  prevailed  in  HW3CCS 
ADP- has  been  one  of  standardizing  software  as  well  as  hard¬ 
ware.  Banagement  procedures  for  the  WHHCCS  standard  ADP 
system  are  promulgated  in  JCS  PUB  19.  Ihe  procedures 
support  the  acquisition,  maintenance,  and  continued  improve¬ 
ment  of  the  NNHCCS  standard  ADP  system  and  apply  to  its 
users.  Objectives  of  these  procedures  include: 

"reduce  the  duplication  of  effort  in  design,  develop¬ 
ment,  acquisition,  and  maintenance  of  wWHCCS  At)E 
hardware,  application  software,  and  system  software. 
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aaxi.ai.ze  the  benefits  of  compatibility  and 
standardization  of  WWMCCS  ADP  hardware,  application 
software,  and  system  software,”  [Ref.  5:  p.  11-14] 


C.  WNHCCS  ADP  STAHDAED  APPLICATIONS  SOFTWARE 


"  Application  software  or  portions  thereof,  devel¬ 
oped  within  a  command,  agency  or  Service  or  for  the 
Chairman,  Joint  Chiefs  of  Staff,  will  often  have 
applicability  to  like  conaand-level  KHMCCS  activi¬ 
ties  or  the  other  command  levels  with  common 
requirements  or  similar  information  needs...  In 

?  articular  where  a  Service,  agency,  or  command  or 
he  Chairman,  Joint  Chiefs  of  Staff,  has  an  existing 
capability  to  perform  a  specific  technical  support 
task,  that  capability  will  be  utilized  to  the 
maximum  extent  feasible  rather  than  initiating  a 
separate  development  effort.”  [Ref.  5,  p.  III-2] 


What  this  means  in  the  WW9CCS  ADP  community  is  that  an 
individual  command.  Service,  or  agency  is  assigned  as  the 
Designated  Responsible  Activity  (DRA)  for  development  and 
standardization  of  a  specific  application  which  has  been 
approved  as  a  standard.  The  OJCS  C3  Systems  Directorate 
maintains  cognizance  over  all  standard  systems  in  an  effort 
to  avoid  unnecessary  duplication  and  attempt  to  meet  a  broad 
spectrum  of  user  requirements. 


By  the  late  1980s,  this  ‘'standard"  WWHCCS  ADP  with 
its  processors  and  associated  software  will  be  techno¬ 
logically  obsolete,  operationally  archaic  and  difficult 
to  support  logistically.  (Modernization  will  require 
both  new  hardware  and  new  applications  software  and 
system  software).”  [Ref.  6:  p.  ES-1] 


Much  of  the  standard  applications  software  was  written 
originally  to  operate  in  a  batch  processing  environment 
which  makes  it-  inefficient  and  often  ineffective  for  crisis 
support  which  generally  requires  interactive  capability.  At 
present  a  data  base  must  be  resident  on  the  same  computer  as 
the  executing  application.  This  means  that  every  site  using 


an  application  must  have  access  to  copies  of  the  relevant 
software  and  data  base  on  the  system  on  which  the  processing 
will  he  done.  Many  commands  have  modified  their  copies  of 
the  standard  applications  to  better  suit  their  unique 
requirements  so  that  it  is  actually  no  longer  the  standard 
applicaticn  software. 
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XIX.  PROBLEMS 


1.  I  BE  CPE  ENVIRONMENT 
1 .  Planning 

The  JCS  has  directed  that  the  Joint  Operation 
Planning  System  (JOPS)  will  he  used  in  planning  for  opera¬ 
tions,  force  deploy sent,  and  support  of  US  joint  military 
operations.  JOPS  supports  planning  under  tine-sensitive  or 
crisis  conditions  with  procedures  which  fora  the  Crisis 
Action  System  (CAS) .  Under  non-crisis,  peacetime  situations 
JOPS  is  employed  in  the  deliberate  planning  process. 

a.  Deliberate  Planning 

Deliberate  planning  consists  of  five  phases 
which  are  outlined  in  Figure  3.1  £Ref.  4:  p.  3] 

The  majcr  product  created  during  the  plan  development  phase 
of  JOPS  is  the  time-phased  force  deployaent  data  (TPFDD) . 
When  planning  is  complete,  the  TPFDD  contains  all  of  the 
information  needed  tc  describe  a  deployment.  TPFDD  refine¬ 
ment  is  conducted  in  a  two-phase  conference  hosted  by  the 
Joint  Deployment  Agency  (JD A) . 

The  WIN  is  utilized  as  a  timely,  secure  means  of 
distributing  data  to  the  deployaent  community  to  facilitate 
the  refinement  process.  Prior  to  the  Phase  I  refinement 
conference  the  WIN  is  used  to  distribute  the  unrefined 
TPFDD,  which  contains  only  notional  data,  to  the  deployment 
community  in  order  that  initial  analysis  can  be  conducted 
prior  to  the  conference.  During  the  Phase  I  conference  as 
actual  forces  are  designated  to  replace  the  notional  forces 
in  the  TPFDD  and  transportation  requirements  are  identified, 
the  TPFDD  is  updated  to  reflect  these  changes  and 
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Phase  I 


Initiation 


Basis:  National  Security  Objectives 

Criteria:  The  Threat 

Planning  Tasks  and  Forces 
Objective:  To  Set  the  Stage 


Phase  II 


Concept 

Development 


Basis:  Mission  Assignment  (Forecast  Situation) 

Criteria:  Force  and  Resource  Allocation 

All  Significant  Factors 

Objective:  Derive  the  Concept  of  Operations 


Phase  III 


Plan 

Development 


Basis: 

Criteria: 


Objective: 


The  Commander's  Concept 
Force  and  Resource  Allocation 

Service  Planning  Factors 
Strategic  Movement  Data 
Concept  Adequacy 
A  Transportation  Feasible, 


implementable  Plan 


Phase  IV 


Plan 

Review 


Basis:  The  Plan 

Criteria:  Adequacy,  Feasibility,  and  Suitability 

The  Dynamics  of  Change 
Objective:  An  Approved  Plan 


Phase  V 


Supporting 

Plans 


Basis: 

Criteria: 

Objective: 


The  Approved  Plan 
Service  Doctrine 
Support  Agreements 
A  Family  of  Plans 


Figure  3.1  Deliberate  Planning. 

distributed  to  the  TOAs.  Each  of  the  TOAs  uses  command 
unique  applications  software  to  prepare  movement  schedules 
supporting  the  requirements  in  the  TPFDD  and  to  check  the 
resulting  schedules  for  feasibility  of  execution,  identif¬ 
ying  shortfalls  (requirements  which  cannot  be  net). 
Hilitary  Airlift  Command  (HAC)  forwards  the  TPFDD  by  BIN  to 
Hilitary  Traffic  Hanagement  Command  (HTRC)  after  identifying 
airlift  in  support  cf  the  plan  and  checking  the  plan  for 
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feasibility*  As  the  provider  for  ground  transportation  ani 
transportation  within  the  continental  United  States,  aiac 
identifies  and  tests  cor  feasibility  the  transportation 
support  to  be  provided  by  MTMC.  The  WIN  is  used  again  to 
forward  the  TPFDD  tc  Military  Sealift  command  (MSC) .  The 
sealift  support  for  the  plan  is  identified,  as  well  as  the 
resulting  shortfalls,  and  the  TPFDD  ,  with  air,  ground,  and 
sea  transportation  identified,  is  forwarded  by  PIN  to  the 
Joint  Deployment  Agency.  In  addition,  the  modified  TPFDD  is 
distributed  to  the  deployment  community  for  review  of  short¬ 
falls  prior  to  the  Phase  II  conference.  During  Phase  II  of 
the  refinement  process  as  shortfalls  are  studied  the  plan  is 
modified  tc  resolve  the  shortfalls,  resulting  in  the 
requirement  for  reflowing  the  transportation  support. 

When  the  TPFDD  has  been  refined  and  the 
resulting  CP1AN  reviewed  and  approved  by  the  Joint  Chiefs  of 
Staff,  it  is  then  entered  into  the  deployment  data  base  at 
JDA  and  is  accessible  to  the  deployment  community  by  means 
of  the  WIN. 

b.  Plan  Maintenance 

An  ongoicg  teleconference  is  maintained  for  each  approved 
OPLAN  in  order  to  provide  a  forum  for  discussing  changes 
required  to  maintain  and  update  the  plans. 

Usually  the  first  15  days  of  airlift  and  the  first  30 
days  or  sealift  are  reviewed  by  the  appropriate  members 
of  the  Joint  Deployment  Community,  who  verify  that  the 
units  and  material  designated  in  the  plan  are  actually 
available,  and  would  most  likely  be  the  ones  used, 
should  the  plan  be  executed...  upon  completion  of  the 
maintenance  cycle,  the  revised  data  replaces  the 
outdated  requirements  in  the  Joint  Deployment  System 
(JDS),  £Bef«.  7 i  p.  13].  *  1  1 

This  review  is  usually  conducted  quarterly. 


c.  Time  -sensitive  Planning 

The  Crisis  Action  System  (CAS)  which  is  utilized 
for  time-sensitive  planning  has  six  phases  as  illustrated  in 
Figure  3.2  [Be£.  4:  p.  7]. 

In  the  situation  development  phase  commanders 
can  use  the  WIN  to  submit  Operational  Reports  (OPREPS)  to 
appropriate  authorities.  CPREP  messages  are  used  to  commu¬ 
nicate  concerning  incidents  or  conditions  which  could  evolve 
into  a  crisis. 

In  the  crisis  assesment  phase  WIN  is  used  to 
conduct  a  teleconference  in  which  representatives  from  the 
NMCC,  the  Service  headquarters,  the  Unified  and  Specified 
Commands,  the  JD A,  and  the  TOAs  participate. 
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Figure  3.2  Crisis  Action  Sjstee 


Id  the  course  of  action  development  phase  the 
RIN  is  utilized  as  the  transmission  mode  for  the  OPEEP-1 
messages  used  to  exchange  required  information.  Using  CPBEP 
messages  on  the  WIN,  JCS  promulgates  a  warning  order,  the 
supported  commander  then  tasks  the  deployment  community  for 
required  assistance  in  developing  or  revising  plans.  The 
depolyment  community  in  turn  forwards  responses  and  the  JDA 
updates  the  JDS  data  base  for  the  plan  being  developed  or 
modified. 

In  the  execution  planning  phase  RIN  is  used  for 
transmission  of  the  alert  order  and  operation  order.  The 
deployment  community  develops  supporting  operation  orders  as. 
required  and  uses  WIN  to  forward  updated  information  to  JDA 
for  inclusicn  in  the  JDS  data  base. 

2-  £2££l&ion 

"The  Jcint  Deployment  System  supports  deployment  execu¬ 
tion  and  sustainment  of  forces.. .After  the  JCS  execute 
order,  the  JDS  must. monitor  status  of  deploying  forces, 
material,  and  non-unit  related  personnel. .. JDA  must  also 
be  able  tc  rapidly  respond  to  changes  in  the  deployment 
as  execution  processes."  [Sef.  7:  p.  16] 

The  JDS  capabilities  supported  by  RIN,  which  are 
available  to  the  joint  deployment  community  during  deploy¬ 
ment  execution  are: 


-  A  teleccnf erence  is  used  to  exchange  textual  informa¬ 
tion  among  the  members  of  the  deployment  community  to 
assist  in  decision  making. 

• 

-  Access  to  the  JDS  data  base  is  available  by  one  of  the 
following  means: 
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—  Direct  access  to  the  JDS  data  base  is 
possible  using  SIN  to  access  the  timesharing 
subsystem  of  the  JDA  host  computer.  By  this 
means  remote  users  can  review  or  update  the 
JDS  data  base. 

~  Transfer  of  portions  of  the  JDS  data  base 
to  remote  sites  is  possible  using  SIN.  Then 
users  at  remote  sites  can  run  command  unique 
applications  programs  using  their  copies  of 
the  JDS  data  base.  These  copies  of  the  data 
base  will  not  reflect  updates  to  the  data  base 
at  JDA  unless  a  later  transfer  is  initiated. 

—  Direct  access  to  the  JDA  data  base  is 
possible  throught  the  JDS  Remote  Users  Package 
(BOP)  which  permits  the  user  to  update  a  local 
copy  of  the  JDS  data  base  while  simultaneously 
updating  the  JCS  data  base  resident  on  the  JDA 
ccnputer.  This  permits  commands  to  have 
access  to  the  most  up-to-date  version  of  the 
JDS  data  base  cn  a  real  time  basis. 

The  RHP  is  ccnsidered  to  be  the  prefered  method  for 
timely  transfer  of  information  between  JDA  and  the  remote 
sites  since  it  not  cnly  provides  the  remote  user  the  capa¬ 
bility  fcr  timely  submission  of  updates  and  changes  but  also 
permits  the  remote  user  to  recieve  changes  simultaneously 
as  the  JDS  data  base  is  updated  by  other  members  of  the 
deployment  community.  In  addition  the  ROP  permits  the 
remote  user  to  run  command  unique  applications  programs 
using  the  local  copy  cf  the  data  base.  "As  part  of  the  ROP, 
the  JCA  has  developed  communication  support  software  called 
the  JDS  Interface  Processor  which  uses  existing  SIN  to 
support  transaction  updates  between  two  PIN  sites  in  near 
real  time."  [Ref.  7:  p.  7  0]. 


The  JDS  also  interfaces  with  MAC  and  MTMC  using  *IN 
to  transfer  information  to  and  froa 

-  the  Integrated  Military  Airlift  Planning  System 
(IMAPS)  at  Military  Airlift  Coaaand 

•  the  Motility  Analysis  and  Planning  System  (MAPS  II)  at 
Military  Traffic  Management  Coaaand. 

These  autosated  interfaces  facilitate  the  timely  exchange  of 
movement  requirements  and  scheduling  information  between  JDA 
and  the  TOAs. 

E.  SPECIFIC  PROBLEMS 

Several  examples  cf  the  kinds  of  problems  which  cccur  in 
processing  in  a  distributed  environment  can  be  found  in 
examining  the  JDS  as  part  of  the  HWMCCS  ADP  support  for  CPE. 

a.  Interface  Between  JOPS  and  JDS 

The  JDS  is  the  ADP  tool  used  to  manage  informa¬ 
tion  in  support  of  deployment  and  OPLAH  execution.  In  order 
to  properly  support  its  mission  the  JDS  must  interface  with 
JOPS  which  is  used  tc  develop  oplans.  The  current  interface 
is,  "time-consuming  and  relies  heavily  on  manual  reviews  and 
manipulation  of  'data*,"  [Ref.  8:  p.  8].  The  JOPS  handles 
notional  data,  dealing  with  types  of  units  rather  than 
specific  named  units.  JDS,  however,  has  in  its  data  bases 
specific  named  units  which  will  be  used  in  specific  plans. 

In  order  to  obtain  the  proper  information  for  the  JDS  data 
base,  manual  reviews  of  the  notional  JOPS  data  are  conducted 
and  after  specific  actual  units  are  named  in  support  of 
requirements,  the  JDS  data  base  is  prepared.  In  addition, 
each  of  the  TOAs  requires  support  froa  command  unique  soft¬ 
ware  to  convert  the  notional  movement  tables  froa  JCPS  into 
schedules  which  use  actual  named  assets.  These  schedules 
are  then  used  to  provide  input  for  the  JDS  data  base. 


The  interfaces  among  these  systems  are  primarily 
manual  at  the  present  time.  In  addition,  although  the  FIN 
is  used  to  transfer  data  between  participating  commands, 
each  command  running  JO?s  uses  its  own  copy  of  the  TP  FDD 
during  processing  as  well  as  its  own  copy  of  the  JOFS  soft¬ 
ware.  Ihis  results  in  considerable  duplication  of  files  and 
a  resulting  requirement  for  extensive  coordination  to  ensure 
each  site  is  using  copies  of  the  same  TPFDD  data  base  in 
order  to  prevent  decrepancies. 

t.  NO PLAN  Support 

"There  are  no  adequate  procedures  to  rapidly 
establish  a  deployment  data  base  in  a  NOPLAN  situation," 
[Ref.  8:  p.  11].  Since  in  the  current  JDS  the  only  way  to 
review  data  is  in  ccnnection  with  one  specific  OPLAN  at  a 
time,  it  is  difficult  to  efficiently  use  data  already  in  the 
data  base  in  support  of  a  N0P1AN  situation.  There  is  not 
even  automated  assistance  to  determine  which  units  are 
tasked  to  support  more  than  one  OPLAN.  This  is  a  deficiency 
in  the  current  system  since  there  is  a  validated  requirement 
that,  "The  JCS  will  review  the  supported  commander's  esti¬ 
mate  and  approve  or  ccdify  the  recommended  course  of  action 
after  determining  tie  effect  on  other  operation  plans  and 
global  capabilities, "  [Ref.  9:  p.  12].  There  is  currently 
no  timely,  efficient  way  for  commanders  to  share  N0P1AN 
information  when  developing  potential  courses  of  action 
without  actually  sending  copies  of  data  bases  or  lengthy 
messages  between  commands. 

c.  Data  Base  Inconsistencies 

The  primary  method  for  transfer  of  data  among 
commands  using  the  JDS  is  the  WIN.  Recent  tests  conducted 
during  a  major  exercise  have  shown  in  a  fairly  small  sample 
of  JDS  data  base  records  that  there  are  numerous 
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inconsistencies  among  copies  ox  the  data  base  at  various 
sites  (Jcint  Deployment  Agency,  European  Command,  Military 
Airlift  Command)  : 


"The  technique  ve  used  to  determine  the  synchronization 
of  JDS  data  bases  vas  to  select  a  sample  of  carrier 
records  and  determine  if  the  information  was  the  same  in 
each  of  the  three  data  bases.  .  .This  oplan  has  thou¬ 
sands  of  carriers,  so  ve  limited  our  sample  to  these 
carriers  ve  knew  had  been  updated — those  with  Deviation 
and  /or  Diversion  reports.  He  retrieved  carrier  mani¬ 
fest  data  on  forty-five  records  stored  at  each  of  the 
three  lgcations  ...  In  summary,  this  very  small  sample 
of  carrier  records  having  been  modified  by  deviation/ 
diversion  reports,  had  a  high  percentage  or  differences 
between  RUP  and  JDS  data  bases."  [Ref.  10] 


The  data  shown  furnishes  examples  of  the  discrepancies 
found:  [fief.  10] 

CARRIER  A 038 9 5  SCH  ARR 

EUCCM  255426ZFEB  AT  BRUSSELS 

JDA  250000 0FEE  AT  BRUSSELS 


Discrepancy:  a  difference  in  scheduled  arrival  tine 


CARRIER  A04526  SCH  DEP 

SUCOH  CITY  OF  COLORADO  SPRINGS  (TDHV) 

JDA  PETERSON  FIELD  (TDHV) 

Discrepancy:  a  difference  in  the  name  associated  with  a 

specific  location  cede 


CARRIER  A04021v- 

EUCCM 

JDA 


SCH  ARR 
251626  ZFEB 
2500000FEB 


Discrepancy:  a  difference  in  the  scheduled  arrival  time 


CARRIER  A04182 
EUCCH 


SCH  ARR 
261651 ZFEB 


CARRIER  DEVIATION 


JDA  260000 OFEE  DELAYED  2  HOURS  DUE  10 

DEMONSTRATION  AT  AFCD 

Discrepancy:  a  difference  in  the  scheduled  arrival  time 
and  a  note  concerning  carrier  deviation  which  only  shows 
at  one  site 

The  need  for  complete,  accurate,  timely  informa¬ 
tion  is  often  taken  for  granted.  In  the  CPE  environment 
this  requirement  is  even  more  challenging  since  all  partici¬ 
pating  commands  need  to  be  working  with  identically  updated 
data  bases  if  they  are  to  make  valid  assumptions  for  plan¬ 
ning  and  executing  oplans. 

d.  Data  Base  Management 

"There  is  also  a  requirement  to  develop  a  system  to  restrict 
access  to  data  and  restrict  the  capability  to  change  data 
elements  within  JDS,"  [fief.  11:  p.  2-10].  Safeguards  to 
prevent  unathorized  changes  to  data  elements  in  the  JDS  are 
insufficient.  An  authorized  JDS  user  with  modify  permis¬ 
sions  may  make  unauthorized  modifications  in  the  data  base 
since  individual  types  of  changes  or  types  of  data  elements 
are  insufficiently  safeguarded. 

A  change  or  update  to  the  JDS  data  base  using 
one  update  module  may  or  may  not  update  relevent  corre¬ 
sponding  data  elements.  For  example,  if  a  carrier  is 
reported  as  sunk  using  one  update  module  a  query  module  to 
display  ships  arriving  on  a  given  date  may  still  display  the 
ship  as  scheduled  to  arrive. 

"A  major  problem  facing  the  deployment  community 
is  the  lack  of  standardization  of  data  elements  between  the 
JOPS,  JDS,  UNIT REP ,  and  OPREP.  Because  of  the  need  to  acco¬ 
modate  the  interface  with  these  systems,  JDA  has  been  forced 
to  pick  and  choose  between  various  data  elements. 
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definitions  and  formats,"  [  Hef .  11:  p.  3-8].  The  following 
are  seme  of  the  problems  resulting  from  the  attempt  to 
interface  these  systems: 

-  data  elements  which  actually  have  the  same  meaning 
have  different  names  (e.g.  different  versions  of  an 
airfield  name  associated  with  the  same  location  code) 

-  data  elements  which  have  the  same  meaning  may  have 
different  units  or  te  calculated  using  different  algor¬ 
ithms  (e.g.  weight  reflected  in  long  tons  on  one  system 
and  short  tons  on  another) 

-  data  elements  which  have  different  meanings  have  the 
same  names  (e.g.  arrival  date  on  one  system  may  be  the 
time  a  unit  will  arrive  in  theatre,  on  another  system  it 
may  be  the  time  a  unit  will  arrive  at  port  of  debarka¬ 
tion) 

As  the  data  base  structure  or  the  basic  software 
of  the  JES  changes,  the  command  unique  queries  written  to 
run  against  the  JDS  data  base  must  also  be  changed. 

C.  BEQOIHEHENTS 

In  July  1983  the  Joint  Chiefs  of  Staff  approved  the 
Joint  Operation  Planning  and  Execution  System  (JCPES) 
Bequired  Operational  Capability.  The  initial  operational 
concept. 


"Addressed  procedures  supported  by  state-of-the-art  AD? 
capabilities  which  „  would  result  in  producing 

matter  of 


capability-constrained  courses  of  action  in  a 


hours  and  completed  plans,  fully  sourced  with  actual 
gnits  tested . against  deployment  and  sustainment  capabil¬ 


ities,  within  da^s*  These  criteria,,  once  achieved. 


represent  a  •  revplutionar  jj  improvement '  to 


ning  system  capabilities.  "  [Hef.  9  ]. 


present  plan- 


JCPES  is  envisioned  as,  "The  foundation  for  our  conven¬ 
tional  ccnaand  and  ccctrol  system,"  and  will  accomplish  its 
functions,  "through  the  interoperation  of  a  central  core  of 
joint  applications  and  various  C2  and  functional  systems  .  . 
.  JOPES  sust  support  the  planning  and  execution  of  multi- 
theater  scenarios  involving  total  commitment  of  O.S.  and 
Allied  forces,"  [Eef.  12]. 

JOPES  will  effectively  replace  the  JOPS  and  JDS  which 
today  support  CPE.  JOPS  and  JDS  are  two  separate  systems 
which  do  not  have  an  automated  interface.  JOPS  is  used  for 
planning  and  JDS  for  execution.  In  JOPES,  software 
supporting  these  functions  would  not  require  the  xanual 
interfaces  required  today.  In  addition,  JOPES  will  be 
required  to  share  data  with  command  unique  applications 
which  support  CPE. 

"JOPES  consists  of  the  policy,  procedures,  software, 
hardware,  personnel  training,  and  connectivity  necessary 
to  facilitate  planning  directing  coordinating,  moni¬ 
toring  and  controlling  military  operations."  [Ref.  9: 
p.  2] 

For  JOPES  tc  work  effectively  the  WWHCCS  community  will  have 
to  develop  and  support  a  distributed  data  base  concept  which 
will  pernit  interfacing  command  unique  software  and  system 
standard  software.  In  a  distributed  data  base,  portions  of 
the  data  are  stored  cn  different  computers.  The  physical 
location  of  the  data  ideally  does  not  affect  processing  and 
is  usually  not  even  apparent  to  the  user.  This  would  elimi¬ 
nate  the  need  for  synchronizing  multiple  copies  of  data 
bases  (except  these  required  for  redundancy).  Such  an  envi¬ 
ronment  would  also  eliminate  the  manual  manipulation  of  data 
currently  required  in  interfacing  the  existing  systems  which 
support  CPE. 
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IY.  BEC  OHM  EM  DAT  10 MS 


1.  CHABGIMG  EMYIRONHENT 

The  current  state  of  the  art  in  automatic  data 
processing  offers  many  management  and  technical  opportuni¬ 
ties  to  facilitate  the  transition  from  the  WWMCCS  Standard 
ADP  of  today  to  the  kind  of  system  reguired  to  support  the 
evolving  needs  of  the  CPE  environment.  The  requirement  to 
share  data  among  commands  in  support  of  CPE  requires  addi¬ 
tional  techniques  and  facilities  not  required  by  a  single 
site  operating  in  isolation.  The  Open  System  Interface 
reference  model  proposed  by  the  International  Standards 
Organization  provides  a  means  to  describe  and  document  the 
interfaces  required  in  a  computer  networking  environment. 
The  capabilities  provided  by  local  area  networking  offer  the 
facility  to  link  internal  command  resources  together  in 
support  of  command  unique  requirements.  The  WtiMCCS 
Information  System  is  the  onging  program  to  modernize  WWMCCS 
ADP  utilizing  modern  technology  to  meet  evolving  require¬ 
ments. 

1 .  Cpen  System  Interface  Beference  Standard 

The  International  Standards  Organization  (ISO) 
proposed  the  Open  System  Interface  (OSI)  Reference  Model  to 
serve  as  a  standard  set  of  network  interfaces  and  protocols. 
The  use  of  the  OSI  Beference  Model  would  be  a  step  toward 
international  standardization  of  the  various  protocols  for 
distributed  processing  networks.  Compatibility  among 

network  nodes  would  be  assured  by  compliance  with  standards 
even  when  software  and  hardware  at  various  sites  are 
supplied  by  different  vendors. 


The  OS  I  standard  is  based  on  a  seven  layer  concept. 
Each  layer  provides  a  portion  of  the  services  required  to 
interface  nodes  in  the  network.  By  breaking  the  interface 
problee  into  seven  layers,  the  implementation  of  different 
portions  of  the  interface  can  be  developed,  tested,  fielded, 
and  acdified  independently.  The  layered  approach  helps  to 
isolate  the  functional  reguirenent  from  the  engineering 
implementation.  As  more  efficient  technology  becomes  avail¬ 
able  the  implementation  cf  a  specific  portion  of  the 
interface  can  be  changed  without  undue  influence  on  the 
users*  interaction  with  the  overall  information  network. 

The  bottom  three  layers  of  the  OSI  model  are  host  to 
imp  protocols  and  the  top  four  layers  are  host  to  host 
protocols.  Only  the  top  two  layers  deal  with  interfacing 
user  applications  and  data. 

LAYER  1:  The  Physical  Layer  supports  the  actual  communi¬ 
cation  connection  between  hosts  and  the  transmission  of 
raw  data  ever  the  established  channel. 

LAYER  2:  The  Data  Link  Layer  ensures  data  received  is 
error  free  and  the  appropriate  acknowledgements  are 
sent. 

LAYER  3:  The  network  Layer,  sometimes  called  the  commu¬ 
nication  subnet  lajer,  is  responsible  for  point  to  point 
routing  of  data  between  its  origin  and  destination. 

LAYER  4:  The  Transport  layer,  also  called  the  Host-Host 
layer,  is  concerned  with  dividing  the  data  into  packers 
for  transmission. 

LAYER  5:  The  Session  Layer  provides  the  capability  for 
users  cf  different  machines  to  establish  a  connection 
between  processes  on  the  machines. 


LIT IB  6:  The  Presentation  Layer  manages  the  exchange  of 
data  between  applications  anywhere  on  the  network.  It 
ensures  the  data  is  in  appropriate  format  for  the  appli¬ 
cation  to  which  it  is  being  sent. 

LAYEB  7:  The  Application  Layer  provides  the  interfaces 
between  user  and  application  and  the  user  and  the 
system. 


Layer 


Name  of  unit 
exchanged 


Manage 


Packet 


Bit 


Tigexe  4.1  let work  Based  on  ISO  OSI  Reference  Model. 
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Figure  4.1  [Ref.  13:  p.  16],  illustrates  a  network 
based  on  the  ISC  OS1  Beference  Model.  The  dotted  lines 
represent  virtual  connectivity  between  similar  layers  on 
different  hosts  while  the  solid  lines  represent  physical 
connectivity.  The  ISO  OSI  provides  a  useful  way  of 
describing  protocols  which  perform  required  network  func¬ 
tions  while  leaving  the  engineering  of  the  implementation  up 
to  the  network  designers. 

2.  local  Area  Networks  (LAN) 

local  area  networks  (LAN)  are  networks  which  prcvide 
high  speed  communications  among  information  processing 
equipment  in  a  limited  geographic  area.  Local  area  networks 
have  evolved  from  previously  existing  methods  of  networking 
and  communicating.  They  provide  the  capability  to  interface 
many  kinds  cf  devices  and  to  exchange  data  with  other  LANs 
or  long  haul  networks.  In  general,  LANs  offer  high  data 
transmission  speed  at  lowered  costs  while  sacrificing  long 
distance  data  transmission  capability.  LANs  are  a  key 
element  in  the  strategy  for  the  HWBCCS  Information  System. 
Attributes  of  LANs  which  are  being  evaluated  for  support  of 
BIS  include: 

flexible  topology 

security 

expandability 

flexibility  in  selecting  transmission  media 
reliability. 

3.  BWB CCS  Information  System  (VIS) 

"The  HHBCCS  ■  Information  System  (HIS)  encompasses  the 
informatics  collection,  processing,  and  display  system 
that  includes  MWBCCS  ADP  and  related  software  systems, 
procedures  and  supporting  telecommunications.  The 
modernization  focus  is  on  the  backbone  of  standard 
RHBCCS  ADP  which  supports  command  systems  .  .  .  The  JPB 
(Joint  Program  flanage^)  focus  will  be  on  software  and 
data  management  techniques. "  [Ret.  14:  p.  ES-1] 
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The  HIS  is  explained  briefly  in  order  to  shed  some  light  on 
the  current  effort  to  improve  HHHCCS  ADP  which  will  affect 
the  ADP  environment  in  which  CPE  users  operate.  The  support 
provided  by  HIS  will  be  implemented  incrementally  thereby 
providing  evolutionary  modernization.  This  will  help  mini¬ 
mize  the  overall  impact  on  command  and  control  users  while 
permitting  advances  in  computer  technology  to  be  utilized. 

"The  SIS  JPM  task  is  to  modernize  and  enhance  the 
command  control  software,  acquire  state-of-the-art  hard¬ 
ware  and  add  capabilities  to  the  command  control 

Process.  These  capabilities  include  automating  the 

andling  of  operational  messages,  distributing  data  and 
enhancing  the  capability  of  command  control  personnel  to 
interact  with  their  information."  [Bef.  IS:  p.  17] 

Figure  4.2  [Bef.  16],  illustrates  the  capabilities 
to  be  provided  by  HIS.  In  implementing  HIS  one  goal  is  to 
maintain  the  separation  of  the  the  engineering  implementa¬ 
tion  fron.the  desired  capabilities.  In  other  words,  various 
commands  may  use  different  hardware  and  software  to  support 
their  sites.  In  addition,  LANs  will  provide  tailored 
support  for  internal  requirements  of  commands  while  still 
permitting  and  interface  with  the  long  haul  network. 

<*•  Sai.?acx 

The  recurring  emphasis  in  state-of-the-art  ADP  tech¬ 
nology  is  interfaces  which  perait  the  separation  of 
engineering  and  function.  This  should  perait  the  users  to 
select  tie  implementation  best  suited  to  their  needs  and 
still  interact  with  other  users  supported  by  different 
implementations.  This  conceptually  permits  systems  to 
continue  to  grow  and  evolve,  making  use  of  new  technology 
without  disrupting  the  supported  functions. 
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Ilgnra  4.2  Oa«r  Capabilities  Supported  by  VIS 


E.  SIAHEABEIZATIOM  -  A  HER  APPBOACH 


The  growing  requirement  for  automated  interfaces  between 
the  programs  and  data  bases  used  by  different  commands  to 
support  CPE  cannot  be  supported  using  the  current  RRMCCS 
Standard  Software.  If  commands  want  to  interface  software 
today,  the  interfaces  must  be  designed  individually  and 
uniguely  tailored  to  the  two  ends  of  the  interface.  Figure 
4.3  illustrates  the  interfaces  which  would  be  required  to 
link  the  software  of  four  members  of  the  joint  deployment 
community  today.  Each  line  represents  a  specific  interface 
developed  between  applications  at  two  commands.  In  this 
example  six  programs  are  required  to  interface  each  of  the 
four  commands  to  each  of  the  other  three. 


Figure  4.3  Interfacing  under  VRHCCS  Today. 


It  is  clear  that  in  addition  to  necessitating  many  man- 
years  of  software  development,  an  interface  would  require 
updating  each  time  an  application  on  one  end  was  modified. 
The  requirement  still  exists,  however,  to  share  data  among 
commands.  In  JOPES, 


"Once  an  originating  agency  updates  its  data  base,  the 
distributed  data  case  concept  will  permit  automatic 
updating,  in  summary  format,  of  all  interrelated  data 

-  .  JOPES  yill  no^  burden  lower  lev$l  staffs 

sive  reporting  requirements  but  will  interface 
nd  and  agency-unique  systems  as  necessary  and 
er  specified  limits  to  rapidly  obtain  inforaa- 


bases  ...  JO 
with  extensive  re 
with  command  and 
within  owner  spec 


JDA  has  cade  progress  with  near  real-tiae  updating  of  data 
bases  located  at  different  coasands  but  the  JOS  requires  all 
participating  coaaands  to  be  using  exactly  the  sane  JDS 
software,  operating  on  the  sane  ffWHCCS  Standard  Hardware. 
This  approach  does  net  perait  the  interfacing  of  ccnaand 
unique  applications  and  data  bases  anong  coaaands. 

In  order  to  obtain  the  benefits  of  tineliness  and  accu¬ 
racy  in  interfaces,  an  ADE  solution  is  preferable  tc  the 
current  nanual  interfaces.  If  the  iWMCCS  comnunity  would 
define  a  core  set  of  data  which  is  required  for  CPE  and 
standardize  the  description  cf  this  data,  each  connand 
seeking  to  interface  with  another  coaaand  would  only  have  to 
develop  an  interface  between  tbe  standard  data  set  and  their 
coaaand  unique  software.  Figure  4.4  illustrates  the  Joint 
Ceployaent  Coaaunity  interfacing  in  this  Banner. 


Figure  4.4  Interfacing  through  a  standard  Data  Set. 

The  total  nuaber  of  interfaces  would  be  reduced  signifi¬ 
cantly  and  each  ccanand  would  only  have  to  plan  cne 
interface  with  the  standard  data  set  in  order  to  interface 
an  application  with  all  other  participating  coaaands.  In 
this  exaaple  the  total  nuaber  of  interfaces  was  reduced  froa 
six  to  four  by  interfacing  through  a  standard  data  set. 
Hore  iaportant,  each  node  new  only  requires  one  interface 
vice  the  three  previously  required.  The  use  of  a  ccaaon 
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interface  permits  many  widely  separated  data  bases  to  func¬ 
tion  virtually  as  a  distributed  data  base.  This  will  help 
meet  the  identified  requirement  for  a  distributed  data  base 
approach  tc  support  JOPES.  It  is  not  a  distributed  data 
base  in  the  routine  sense  but  rather  an  interface  which 
permits  the  exchange  of  data  among  separate  data  bases. 
This  ccncept  is  further  developed  in  a  later  section. 


1.  Electronic  Data  Interchange  1 2D  I) 


a.  Background 


"The  O.S.  Electronic  Data  Interchange  (SCI) 
Standards  are  designed  to  facilitate  the  electronic  inter¬ 
change  of  data  in  a  standard  manner  between  independently 
organized*  owned  and/or  operated  computer  and  communications 
systems*"  [Hef.  17:  p.  9].  The  EDI  standards  were  devel¬ 
oped  in  an  extensive  joint  government-industry  effort  to 
meet  a  recognized  need  in  the  transportation  industry  for 
timely*  reliable  transmission  of  data  among  organizations. 
The  organizations  utilizing  the  EDI  standards  include: 


flotor  Carriers 

Ocean  Carriers 

Air  Carriers 

Bailroads 

Brgkers 

Shippers 

Consignees 

Freight  Forwarders 

Freight  Ccnsolidatcrs 

Banks 

Agents 

O.S.  Customs  Service 
O.S.  Department  of  Agriculture 
O.S.  General  Services  Administration 
O.S.  Department  of  Defense. 


b.  Structure  of  EDI 


The  major  unit  of  information  in  EDI  is  the 
transaction  set.  Transaction  sets  support  the  major  func¬ 
tions  performed  by  the  communicating  organizations. 
Information  units  in  the  EDI  include: 


"Data  Element:  The  smallest  information  unit  in  the  EDI 
information  structure  is  the  data  element.  A  data 
element  may  be  a  single  character  code,  a  series  of 
characters  constituting  a  literal  description,  or  a 
numerical  quantity. 

pata  Segment:  A  data  segment  is  composed  of  a  function 

identifier  and  one  or  more  functionally  related  data 
elements  positioned  serially  in  a  standard  manner  .  .  .A 
segment  is  roughly  equivalent  to  a  line  of  information 
on  a  bill  of  lading  or  freight  bill. 

Transaction  Set:  A  transaction  set  is  a  group  <?f  data 

segments,  in  a  predfined  sequence,  needed  to  provide  all 
of  the  data  required  to  define  a  complete  transaction 
sucfc  a  s  shipment  information  or  invoice  .  The  trans¬ 
action  set  in  EDI  eguates  to  a  document  in  a  paperwork 
system,  such  as  a  bill  of  lading  or  invoice. 

Functional  Gpoup  cf  Transaction  Sets:  A  functional 

?roup  identifies  those  transaction  sets  of  the  same  type 
having  the  same  mdentifier  and  subject  title)." 
Hef.  18]  J 


Figure  h.5  [fief.  19],  shows  bow  the  information  units  are 
put  together  to  build  a  complete  transaction  set.  The  first 
data  segment  shown  in  the  second  column  of  the  example  is 
composed  of  the  first  four  data  elements  in  the  first 
column.  This  same  data  segment  becomes  the  first  part  of 
the  transaction  set  in  column  three.  It  should  be  noted 
that  a  data  element  (e.g.  A)  can  be  used  in  more  than  cne 
data  segment. 


■  BUSINESS 

INFORMATION  UNITS  APPLICATION 


Figure  4.6  £Bef.  19],  shows  how  a  communications 
session  with  a  user  inputting  data  into  the  network  can 
include  sore  than  one  transaction  set.  This  figure  follows 
the  building  block  approach  by  showing  that  related  trans¬ 
action  sets  (e.g.  purchase  orders)  can  be  regarded  as  a 
functional  group  and  several  related  or  unrelated  functional 
groups  can  be  sent  in  the  same  transmission. 

c.  EDI  Operations 

The  EDI  ccncept  operates  through  the  use  of  five 

tables. 

"The  same  five  tables  are  used  for  generation  of  data  to 
be  transmitted  and  for  the  interpretation  of  data  that 
is  received.  The  set  of  tables  defines  the  structure 
and  attributes  of  the  EDI  transaction  sets,  segments, 
data  elements,  and  cgdes.  The  EDI  operational  software 
programs  control  pcrnters  to  these  tables  and  use  the 
information  at  the  pointer  locations,  in  combination 
with  data  from  the  user’s  data  base,  to  assure  program 
generation  and  interpretation  of  data."  [Bef.  19  j 

These  tables  are  used  to  process  incoming  and  outgoing  data. 
Figure  4.7  £Bef.  19],  explains  generally  how  the  tables  are 
used.  Figure  4.8  £Bef.  19],  presents  a  more  detailed 
example  of  the  data  structure,  with  sample  entries  for  each 
table  described  in  figure  4.7  Table  1  has  a  list  of  all 
transaction  sets  with  identifying  numbers.  Table  2  lists 
the  data  segments  in  each  transaction  set.  Table  3  is  a 
directiory  of  all  data  segments  with  identifying  numbers. 
Table  4  lists  the  data  elements  in  each  data  segment.  Table 
5  is  the  data  dictionary  and  is  broken  down  by  data 
elements.  Detailed  examples  of  each  table  are  given  m  a 
later  section.. 
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Table  1  is  used  to  locate  items  in  Table 

2. 


Table  2  gives  the  order  of  segments  in  a 
transaction  set  for  each  application. 


Table  3  is  used  to  locate  items  in  Table 
4. 


Table  4  gives  the  order  of  data  elements 
in  each  segment. 

Table  4  example  (simplified) : 


Segment  I.D. 


Data  Element 


Location 


EX  (Example) 

EX 

EX 

EX 


Table  5  specifies  data  element  attributes. 
Table  5  example  (simplified) : 


Data  Element 


Maximum  Length 
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Figure  4.8  EDI  Tables  -  Sasple  Entries 


d.  Advantages  of  SCI 


The  emphasis  in  the  EDI  concept  is  on  communica¬ 
tions  (exchange  of  information)  between  computers.  By 
communicating  through  the  use  of  standard  transaction  sets, 
EDI  permits  users  to  interface  efficiently  while  preserving 
their  autonomy.  Each  user  could  conceivably  be  using 
different  kinds  of  hardware,  software,  and  data  base  manage¬ 
ment  systems  and  still  be  able  to  communicate.  An  added 
benefit  of  the  EDI  approach  is  that  data  elements  can  be 
added  or  deleted  without  reguiring  software  logic  changes. 
Also,  changes  in  a  user's  applications  will  not  affect  the 
interface  with  other  users  as  long  as  the  translation  tc  the 
EDI  standard  is  updated  within  the  command. 

The  EDI  concept  could  be  used  within  the  WWMCCS 
community  tc  ease  the  transition  to  the  distributed  data 
base  environment  which  will  be  required  to  support  CEE.  To 
implement  this  approach,  members  of  the  HflMCCS  community 
would  have  to  define  the  applications  and  the  data  which  are 
required  to  support  CEE.  Standard  methods  for  data  control 
would  be  required.  Once  the  standards  were  developed  and 
documented  it  would  be  the  responsibility  of  each  command  to 
make  the  translation  between  their  applications  and  the 
standard.  Cnee  all  the  involved  commands  are  able  tc  trans¬ 
late  between  their  applications  and  the  standard,  they  could 
also  communicate  directly  with  other  participating  commands. 

2.  Application  tc  Specific  Problems 

The  desirability  of  implementing  the  EDI  concept 
within  the  HWHCCS  community  can  be  evaluated  by  examining 
how  it  would  help  resolve  the  some  of  the  problems  which 
have  been  identified  in  VflUCCS  ADP  support  of  CPE. 


9 
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a.  Data  Base  Management 

In  order  to  ensure  the  accuracy  of  data  the 
capability  to  modify  or  delete  data  must  be  controlled.  The 
current  system  dees  net  protect  against  unauthorized  changes 
made  by  a  user  who  is  authorized  access  to  some  but  not 
neccessarily  all  data.  The  EDI  concept  would  contribute  to 
security  because  the  data  elements  would  be  distributed 
among  the  commands  with  ultimate  control  and  modify  permis¬ 
sions  held  by  the  command  "owning"  the  data  and  responsible 
for  its  accuracy.  Another  command  could  reguest,  data  tut 
the  system  would  check  to  validate  the  identity  of  the 
sender,  in  accordance  with  pre-arranged  agreements, 

"The  communications  protocol  provides  a  means  for  posi¬ 
tive  identification  of  the  sender  by  the  receiver,  and 
conversely  ...  Processing  of  transmissions  which  do 
not  pass  the  comnmunication  header  validation  tests  is 
aborted  after  an  error  reply  is  sent  to  the  sender  and 
the  conditions  have  been  logged  for  subsequent  study  or 
analysis."  [Ref.  17]  * 

By  distributing  the  data  and  controlling  communications 
access  tc  specific  data,  the  EDI  concept  provides  more  secu¬ 
rity  than  the  current  system. 

In  the  current  system  a  change  or  update  to  the 
JDS  data  base  using  one  update  application  may  or  may  not 
update  relevent  corresponding  data  elements.  Using  the  EDI 
approach,  many  applications  could  rely  on  a  single  ccpy  of  a 
data  element  so  the  opportunity  for  discrepancies  would  be 
minimized.  Today  different  applications  use  different  files 
and  it  is  difficult  tc  effectively  update  all  instances  of  a 
data  element.  In  addition,  through  use  of  the  transaction 
sets,  groups-  of  related  data  elements  could  be  updated 
together. 
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The  current  lack  of  standardization  of  data 
elements  aaong  standard  and  command  unique  systems  can  be 
significantly  reduced  through  the  use  of  the  EDI  concept. 
Initially  an  effort  would  be  required  to  identify  data 
eleaents  which  aust  be  shared  among  members  of  the  KHaccs 
coaaunity.  The  definitions  of  these  data  elements  would  be 
specified  and  incorporated  into  a  standard.  Each  command 
which  needs  to  interface  with  another  in  the  community  would 
then  develop  the  necessary  software  to  translate  command 
data  elements  into  the  standard  format.  “The  interface 
computer  prcgraa  and  the  structure  of  each  type  of  trans¬ 
action  set  are  part  of  the  EDI  standards.  EDI  does  not 
address  a  standard  which  extends  into  a  company* s  internal 
system, "  [Bef.  17].  The  EDI  software  would  perform  the 
functions  which  would  facilitate  interfaces  aaong  partici¬ 
pating  commands.  Cnee  data  to  be  interchanged  has  been 
defined  in  a  standard  definition,  individual  commands  can 
convert  data  elements  to  the  standard  through  individual 
software  routines.  This  would  resolve  the  following  kinds 
of  discrepancies: 

-  data  elements  which  actually  have  the  same  meaning 
have  different  names 

-  data  eleaents  which  have  the  same  meaning  may  have 
different  units  or  be  calculated  using  different  algor¬ 
ithms 

-  data  elements  which  have  different  meanings  have  the 
same  names 

As  the  data  base  structure  or  the  basic  software 
of  the  JCS  changes,  the  command  unique  queries  which  rely  on 
the  JCS  data  base  often  aust  be  rewritten.  The  EDI  concept 
is  designed, 

"To  respond  with  ease  to  frequent  requirements  for  modi¬ 
fication,  contraction,  and/or  expansion  of  the 


'  "  v  •  .  ■  ■ .  •  -  -  *  -  ■  ■  _  *  "  .  *  .  *  _  m  \  * 


individual  applications.  .  .  the  information  is 
structured  sg  chat  it  say  be  constructed  by  one  computer 
system  and  interpreted  and  processed  by  another.  New 
applications  and  information  units  may  be  specified 
without  impacting  work  previously  completed."  [fief.  17: 
pp.  6-13] 

The  physical  implementation  (e.g.  the  programming  languages 
and  the  data  base  management  system)  of  any  standard  or 
unique  application  is  kept  isolated  from  the  standard  data 
definitions  so  modifications  to  implementation  methodology 
will  not  destabilize  the  system. 

b.  Data  Base  Inconsistencies 

The  problem  of  different  sites  having  different 
copies  of  the  data  base  would  be  avoided  through  the  EDI 
concept  because  of  the  distribution  of  data.  Each  data 
element  would  reside  at  the  command  responsible  for  its 
accuracy  but  would  be  accessible  to  other  commands.  Even 
with  provision  for  redundancy  this  is  still  a  more  desirable 
arrangement  than  multiple  copies  of  data  bases  residirg  on 
many  systems  at  many  locations.  In  this  way,  as  data  is 
updated  for  one  purpose  (e.g.  UNITHEP)  the  updated  data 
would  also  be  available  for  other  applications  such  as  JCPS 
or  JDS  withcut  requiring  separate  updates  for  each  applica¬ 
tion. 


c.  NOPLAN  Support 

The  use  cf  the  EDI  concept  could  help  in  a 
NOPLAN  situation  by  eliminating  the  necessity  to  send  copies 
of  entire  data  bases  or  lengthy  messages  among  commands.  As 
each  ccnand  successively  develops  a  portion  of  the  plan, 
data  can  be  ex-tracted  from  applicable  data  bases,  incorpo¬ 
rated  into  transaction  sets  and  transmitted  to  ether 
involved  commands.  Because  the  construction  of  new 
instances  of  a  transaction  set  can  be  facilitated  by  the  EDI 
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tables  it  would  be  such  easier  for  commanders  to  evaluate 
various  alternatives  since  less  data  would  have  to  te  sent 
among  commands  to  generate  responses  to  "what  if  "  ques¬ 
tions.  It  would  also  be  possible  to  include  as  part  of  the 
information  on  a  specific  unit  the  various  OPLANs  in  which 
the  unit  was  tasked.  This  could  be  done  by  developing  a 
data  segment  which  includes  as  data  elements  the  unit  desig¬ 
nation  ard  the  plans  which  task  it.  In  this  way  potential 
problems  with  multi-tasking  could  be  identified  quickly. 

d.  The  Interface  Between  JOPS  and  JDS 

The  interface  between  JOPS  and  JDS#  and  other  standard  or 
command  unique  applications  could  be  significantly  sitpli- 
fied  through  the  EDI  CONCEPT.  Since  incompatibility  of  data 
elements  is  not  a  problem  when  the  common  interface  is  used, 
data  from  numerous  systems  could  be  tapped  in  response  to 
information  queries  input  using  any  one  of  the  systems. 

C.  I IP LEHE STATION 

Although  the  EDI  concept  requires  a  standard  set  of  data 
elements  in  order  to  operate,  there  is  no  centralized  stan¬ 
dard  data  base.  EDI  facilitates  the  transfer  of  data  among 
various  data  bases  by  means  of  a  common  interface.  Laying 
the  groundwork  for  an  EDI  interface  is  in  some  ways, 
however,  similar  to  data  base  design.  It  will  be  helpful  to 
examine  the  necessary  preparation  for  implementing  ELI  in 
data  base  design  terms. 

A  data  base  is  a  model  of  an  organization  which  exists 
in  the  real  world.  Events  which  occur  in  the  real  world  are 
reported  to  t-he  data  base  system  as  transactions  which  in 
turn  cause  data  to  be  modified.  Design  considerations  for 
data  bases  as  models  are  listed  in  figure  4.9  [Ref.  20:  p. 


Database  as  a  modal  of  an  antarprlsa 
Laval  of  detail 

Cost  of  aggregation  and  generalization  is  unanswerable  question 
Need  to  aggregate  and  generalize  in  light  of  requirements  and 
financial  resources 

Dynamics  of  database  as  model 

Enterprise  changes,  model  must  change 

Events  occur,  are  represented  by  transactions 

Level  of  transaction  important  -  transactions  cannot  be  more 

aggregated  or  generalized  than  database  data 

User  views 

Different  perception  of  data  structure 
Different  perception  of  data  meaning 
Need  for  standardized  meaning 


Figuxe  1.9  Design  Considerations  for  Databases  as  Hodels. 


The  fact  that  in  CPE  users  represent  nan;  commands  with 
different  slews  can  cause  a  design  problem. 


"Different  users  <and  designers)  will  have  different 
aeanings  and  interpretations  for  data  that  is  stored  in 
the  database.  Questions  that  appear  to  be  siailar  may 
in  fact  be  different."  £  Hef.  20:  p.  177] 


Definition  of  a  set  of  data  elements  which  must  be 
available  in  an  EDI  interface  would  require  a  great  deal  of 
effort  with  high  level  support  in  the  joint  arena.  The 
standard  data  elements  will  be  the  building  blocks  from 
which  interfaces  will  be  constructed. 


'Data  base  design 
design,  where  th 
physical  design. 


is  divided  into  two  phases:  logical 
e  needs  of  people  are  specified,  ana 
where  the  logical  design  is  mapped  into 
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the  constraints  cf  particular  program  and  hardware 
products,”  [Ref.  2C:  p.  177]. 

The  logical  data  base  design  is  done  by  the  users  uhc  need 
to  use  the  data.  The  physical  data  base  design  is  normally 
done  by  experts  skilled  in  evaluating  hardware  and  software 
capabilities  and  selecting  the  lost  feasible  means  of  imple¬ 
menting  the  logical  design.  This  division  of  effort  would 
apply  also  in  a  general  way  to  designing  a  standard  EDI 
interface,  although  it  is  not  a  data  case  management  system 
per  se. 

1 .  logical  Data  Ease  Design 

a.  The  Output 

The  output  of  a  logical  data  base  design  is  a 
schema  which  defines  the  data  records  (in  EDI  terminology, 
the  data  segments)  which  are  to  be  maintained,  the  data 
elements  which  compose  them,  and  the  relationships  amcng 
these  data  segments  and  data  elements.  Data  segments  are 
described  by  listing  the  data  elements  which  they  contain 
and  constraints  which  limit  the  values  the  data  can  have. 
Transaction  sets,  in  turn,  are  described  by  listing  the  data 
segments  they  contain  and  applicable  constraints. 

b.  Input 

The  inputs  of  the  logical  data  base  design  are  the  system 
requirements  and  the  plan  which  describes  the  envircnment 
and  constraints,  which  will  affect  the  system. 

c.  Procedures 


"The  majci  steps  in  the  logical  design  process: 

-  identify  data  to  be  stored 

-  consolidate  and  clarify  data  names 

-  develop  the  logical  schema 

-  define  processing  _  _ 

-  review  design,”  fBef.  20:  p.  1811. 


In  the  process  of  identifying  the  data  tc  be 
stored,  the  data  dictionary  is  developed  and  data  elements 
are  identified  by  name  and  described.  Figure  4.10 
[Bef.  18 j,  is  an  example  of  a  portion  of  an  EDI  data 
dictionary.  To  see  how  the  data  dictionary  is  set  up, 
consider  data  element  "10"  in  the  left  column.  Data  element 
"10"  is  defined  as  a  six  digit  numeric  field  which  is 
entered  with  the  first  two  digits  representing  the  last  two 
digits  of  the  year,  the  middle  two  digits  representing  the 
month,  and  the  last  two  digits  representing  the  day  of  the 
month.  This  physical  description  of  the  data  element  is 
also  accompanied  by  a  verbal  definition  of  the  data  element. 

To  consolidate  and  clarify  data  names  it  is 
necessary  to  identify  synonyms  and  aliases.  Synonyms  are 
different  names  for  the  same  data  element.  Synonyms  should 
te  reduced  to  one  standard  name.  Aliases  are  alternate 
names  for  the  same  data  element  (synonyms)  which  are 
permitted  to  remain  in  the  system.  EDI  eliminates  the  need 
for  aliases  because,  Although  different  users  may  have 
different  names  for  the  same  data  element,  they  can  provide 
for  "translation"  to  the  standard  by  means  of  the  software 
they  design  to  interface  their  unique  system  to  the  EDI 
standard. 

The  development  of  the  logical  schema  consists 
of  defining  data  segments  and  their  relationships.  Figure 
4.11  and  figure  4.12  are  samples  of  two  EDI  tables  which 
list  data  segments  and  the  data  elements  from  which  they  are 
tuilt.  [Bef.  19].  In  Table  3  (figure  4.11)  the  data 
segment  titled  "beginning  segment  for  completed  payments"  is 
assigned  the  segment  ID  number  ”B7”.  This  data  segment  is 
composed  of  three  data  elements  (see  the  right  column) . 
These  data  elements  can  be  identified  using  Table  4  (figure 
4.12)  by  finding  the  segment  ID  number  "B7"  in  the  first 
column.  The  second  column  lists  each  data  element 
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associated  vita  the  data  segment  and  the  third  column  indi¬ 
cates  whether  the  data  element  is  mandatory  (M)  ,  optional 
(0)  ,  or  conditional  (C)  .  Additional  information  is 
contained  in  the  remaining  columns.  These  tables  are  used 
in  ccnjunction  with  the  data  dictionary  which  describes 
individual  data  elements,  to  form  the  logical  schema. 

To  define  processing,  transactions  should  be 
defined.  Transacticns  represent  events  in  the  real  world 
and  in  ECI  transaction  sets  represent  paperwork  which  docu¬ 
ment  a  real  world  event.  Transaction  sets  are  defined  in 
terms  of  the  data  segments  from  which  they  are  built.  in  a 
sense  this  is  an  extension  of  the  logical  schema.  Figures 
4.13  and  figure  4.14  are  a  sample  of  two  EDI  tables  which 
list  transaction  sets  and  the  data  segments  they  include 
[fief.  19].  In  Table  1  {figure  4.13)  the  transaction  set 
titled  "flight  confirmation"  is  assigned  set  ID  number 
"101".  This  transaction  set  is  composed  of  eight  data 
segments.  These  data  segments  can  be  identified  using  Table 
2  (figure  4.14)  by  finding  the  set  title  "flight  confirma¬ 
tion"  and  the  set  ID  number  "101".  The  second  column  under 
"flight  confirmation"  lists  each  data  segment  associated 
with  the  transaction  set  and  the  third  column  indicates 
whether  its  use  is  mandatory,  optional,  or  conditicnal. 
Additional  information  is  provided  in  the  remaining  columns. 

The  purpose  of  a  design  review  is  to  identify 
flaws.  Documentation  from  the  previous  stages  is  examined 
and  problems  are  identified  and  recommendations  for  resolu¬ 
tion  are  made. 

2.  Physical  Da£a  Base  Design 

Since  EDI  is  not  a  data  base  management  system  as 
such,  the  steps  of  physical  data  base  design  apply  only  in  a 
loose  sense.  The  physical  design  differs  from  the  logical 
design  primarily  in  the  sense  that  the  physical  schema 
provides  for  the  implementation  of  the  logical  schema. 


TABU  4  -DATA  ELEMRITS  IN  EACH  SEGMENT 
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figure  4-1*  Data  saga ants  in  Bach  Transaction  Sat. 


a.  output 

The  outputs  of  the  physical  design  are  the  phys 
ical  schema  and  the  definition  of  user  views.  The  physical 
schema  includes  specific  data  structures  (e.g.  linked  list 
or  inverted  lists)  and  the  necessary  algorithms  to  mairtain 
and  manage  the  data  base.  The  physical  schema  is  in  execu¬ 
table  fora.  The  definition  of  user  views  in  the  EDI  sense 
would  be  the  interface  software  which  would  link  a  unigue 
data  base  at  a  specific  command  to  the  EDI  standard  in  crder 
to  translate  the  data  for  transmission. 

3-  iSJ!M£X 

The  design  effort  required  to  implement  an  EDI 
interface  within  the  tfWMCCS  community  is  really  at  two 
levels.  At  the  joint  community  level  a  logical  design  must 
be  produced  by  the  users  and  a  physical  schema  by  the  appro¬ 
priate  technical  experts.  At  the  command  level  software 
must  be  developed  to  interface  command  unigue  data  bases  to 
the  EDI  standard  in  order  to  enable  commands  to  successfully 
exchange  data  while  still  preserving  their  unique  systems. 


f.  SOBBABY 


One  cf  the  major  problems  in  WWMCCS  ADP  today  is  the 
inability  tc  meet  tie  requirement  for  timely  exchange  of 
data  among  widely  separated  commands  in  a  time  sensitive 
environment  while  preserving  security  and  accuracy.  The 
current  method  is  to  have  commands  use  their  unique  applica¬ 
tions  for  individual  processing  requirements  and  then  use 
one  of  a  few  standard  applications  in  order  to  interface 
with  other  commands  in  a  form  which  can  be  interpreted  by 
them.  This  method  entails  many  problems,  not  the  least  of 
which  is  a  requirement  for  manual  intervention  to  translate 
data  among  various  applications.  Manual  intervention 
increases  the  likelihood  of  problems  with  timeliness,  accu¬ 
racy,  and  security. 

By  implementing  the  EDI  concept  the  members  of  the 
SWBCCS  community  could  substantially  reduce  these  problems 
by  reducing  the  requirement  for  special  interfaces  (manual 
or  automated)  between  each  set  of  applications  which  need  to 
exchange  data.  By  csing  the  EDI  concept,  any  command  which 
could  translate  to  and  from  the  EDI  standard  data  set  could 
exchange  data  with  any  other  participating  command. 

Figure  5. 1  shows  how  data  sets  are  exchanged  among 
commands  today.  each  dotted  line  represents  an  interface 
program  designed  to  "translate"  data  between  an  application 
at  one  command  and  an  application  at  another.  Today  if  BSC 
is  to  furnish  information  directly  to  three  applications  at 
other  commands  (e. g.  flTMC,  JDA ,  MAC)  special  interface  soft¬ 
ware  must  be  written  or  all  commands  must  be  restricted  to 
using  the  same  software  and  hardware.  In  addition,  if  any 
other  commands  needed  to  exchange  data,  they  would  need 
additional  software  to  facilitate  those  interfaces  (eg.  BIHC 


and  JDA) .  Figure  5.2  Indicates  how  data  would  be  exchanged 
using  the  IEI  concept.  A  saople  data  exchange  using  data 
will  serve  to  further  illustrate  the  function  of  the  £01 
standard  data  set. 

MAC . NSC . MTHC 

JO  A 

Figure  5.1  BVHCCS  Interfaces  Today. 


Figure  5.2  Data  Exchange  Using  EDI. 


HSC  is  required  to  transmit  information  which  contains 
in  it  ,a  data  element  which  represents  a  date.  They 
transait .this  information  to  JDA,  Mine,  and  MAC.  Due  to 
their  unique  applications,  MSC  represents  this  date  as 
hour-ainutes-aonth-day-year  (eg.  2250061285). 

Jhe  MSC-EOI  interface  translates  this  to  the  EDI  stan- 
ard  for  date  which  is  expressed  (by  coaaunity 
agreeaent)  as  day-aenth-y ear  (eg.  120685). 

The  EDI  software  packages  the  information  for  transmis¬ 
sion  and  sends  it  to  the  appropriate  commands. 


When  the  data  is  received  at  JDA,  they  translate,  using 
coaaand  §c£tvare,  into  the  foraat  required  tv  unicue 
applications  at  JDA  (eg.  year-*- month- day  850612).  SHen 
the  data  is  received  at  MIMC  it  is  used  in  the  EDI 
foraat. 

The  acst  obvious  advantage  is  that  if  MTHC  also  interfaces 
with  JDA  nc  additional  interfaces  would  be  required  using 
the  ECI  concept. 

The  EDI  systen  provides  for  the  transmission  of  the  data 
in  a  standard  foraat.  Each  coaaand  provides  the  Keans  of 
translating  their  data  to  to  and  froa  the  standard  with 
command  unique  software.  This  does,  however,  reduce  the 
nuaber  cf  required  interfaces  and  permits  reduction  of 
duplication  in  establishing  a  distributed  data  base 
approach.  Each  coaaand  will  only  require  one  interface, 
regardless  of  the  total  number  of  coaaands  participating. 
Under  the  current  systen,  if  each  coaaand  is  to  exchange 
data  with  every  other  participating  coaaand  the  total  nuaber 
of  interfaces  required  for  each  command  would  be  M-1  (where 
N  represents  the  nuaber  of  coaaands  participating) .  The  EDI 
standard  tables  could  contain  codes  indicating  which  coaaand 
is  responsible  for  certain  kinds  of  transaction  sets  or  data 
segaents  and  to  whoa  these  are  distributed.  In  addition, 
when  information  is  requested  through  the  EDI  interface,  the 
central  directory  would  have  the  means  to  locate  the  appro¬ 
priate  command  from  which  to  draw  the  information.  This 
would  reduce  the  require  aent  for  each  command*  to  maintain 
individual  data  directories  for  all  the  coaaands  with  which 
they  interface.  The  use  of  a  common  interface  permits  many 
widely  separated  data  bases  to  function  virtually  as  a 
distributed  data  base.  This  will  help  meet  the  identified 
requireaent  fair  a  distributed  data  base  approach  to  support 
JOPES.  It  is  not  a  distributed  data  base  in  the  routine 
sense  but  rather  an  interface  which  permits  the  exchange  of 
data  aaong  separate  data  bases. 


59 


The  EDI  concept  does  work.  It  is  being  used  in  the 
transportation  industry  today.  Figure  5.3  and  Figure  5.4 
are  provided  as  a  further  illustration  of  its  application 
[Be£.  21].  In  figure  5.3  the  sender  types  information  into 
a  terminal  in  the  format  required  by  the  individual  organi¬ 
zation  (in  this  case  using  a  forms  mode  and  "filling  in  the 
blanks") .  Figure  5.4  shows  how  the  same  data  appears  when 
it  has  keen  converted  into  EEI  standard  data  elements  and 
data  segments  by  means  of  the  table  driven  EDI  system. 

Qse  of  the  EDI  concept  in  HHHCCS  would  require  high 
level  support  and  commitment  throughout  the  joint  community. 
The  initial  effort  tc  develop  standard  data  sets  and  prepare 
command  interfaces  is  indeed  significant.  However,  since  it 
will  provide  the  capability  to  exchange  data  among  commands 
using  various  hardware,  software,  and  data  base  management 
systems,  it  has  the  obvious  advantage  of  providing  much 
needed  flexibiltiy.  Commands  would  be  able  to  utilize  state 
of  the  art  ADP  technology  tc  solve  their  unique  command  and 
control  ADP  requirements  without  sacrificing  the  capability 
to  exchange  data  effectively  with  other  commands.  By 
providing  for  data  transfer  without  requiring  standarization 
and  duplication  of  applications  and  data  bases,  EDI  supports 
more  efficient  use  cf  ADP  resources.  The  EDI  concept  can 
help  sove  the  data  exchange  problems  in  WHHCCS  ADP  today  and 
contribute  toward  fullfilment  of  evolving  requirements  for 
exchanging  data  among  commands. 


i  i«v  a  i  c  & 

( Samp  1 •) 

ABC  Company,  Inc.,  Anytown,  California 
<«:•  »uttr 


illi.  T3i 

La  i  •«  Coao.nv 

( JC3  *  96765432 10<XC> 

«ttr. :  Accounting  2»uL. 

1  T  O  ■.  MiJiiOI.  At'C. 

FroofliO  Jrit*  J  r. .  CA  c4273 

Sr"  TE: 

2«.i •!  Cc.ir.OJ.-i. 

iCCS  #  9676143210070) 
Grscar .  ^aretisiuti-  *  70 
22  «i«(t  i_orta  St. 
RicSiano.  CA  ~43-X' 


urau  **££•: 

44  ac  ~Cll 


PcSLrrii  5":: 

VC34 : 7 


INtEICl  11*1. 

Is  Oct  1982 


27.  SO  Net  20 


mu w:t  i»: 

»nia 


vacs  asr 


C53;?:=?:st 


:;r  i*:t  a:Miai 
KsT  fc_S«. 


1C-  CS  -X  77 1791 2341  24'ii  CE  ABC  Trfcil  Fruit  5*1*0  13.17  131.70 

1  23  ‘XT' 17V 12742  24/1*  22  AflC  Trpcl  Fruit  Salad  NC  0.00 

30  CS  0037 i 396759 :  24/S  02  ABC  Cwt  Grpen  enr>E  9.7fc  292.  bO 


total: 


*424.20 


SPECIAL  IISTMJETICKS 


Figurs  5.3  Transalssion  as  Sabsittsd 


TRANSACTION  SET  EXAMPLE  -  INVOICE  #  44887221 
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Figaro  5.9  Transmission  in  EDI  Fornat. 
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